Business Rule Management (BRM) technology relates to the area of decision-making automation in business problems, such as loan approval, insurance claim processing or customer loyalty programs. A Business Rule Management System (BRMS) is implemented to work with rule projects. A BRMS allows rule edition in a controlled natural-like language, which makes it easy to use without specific knowledge on generating rules. The rules can be kept in different versions in a rule repository. A BRMS further allows the execution of the rules by a rule engine, which also performs a rule analysis for detecting conflicting rules, redundant rules, and missing rules. Another feature is rule validation by test and simulation.
Business rules are a convenient way to represent decision making policies that are making decisions depending on given cases. A case usually consists of a combination of features and a decision may be a combination of elementary choices. A business rule makes a decision by applying an action to a given case. A business rule cannot handle all cases, but only those that satisfy a condition. A business rule thus consists of a condition, which usually is a combination of tests, and an action, which may consist of a sequence of elementary steps. As a business rule treats only certain cases, it defines only a part of the whole decision making process. Further business rules are needed to make a decision for the remaining cases. If the given business rules are making a decision for each relevant case, then such a collection of rules is complete. Otherwise, the rules will not treat every case and further rules need to be added to make the rules complete.
Decision automation for problems, such as insurance claim processing, loan approval, or discount calculation for shopping carts consists in making decisions for a huge number of cases in a consistent and predictable way. Decision automation is achieved through business policies comprising business rules, which map each possible case to a single decision. Business rules provide a convenient way to represent complex policies which make decisions for diverse and complex forms of cases. Each rule represents an independent part of the policy and makes a decision for a subset of the cases. A business rule consists of a condition describing the cases treated by the rule and an action which consists in making the decision for a case. As cases may be complex and consist of different objects (such as the different items in a shopping cart), a business rule may treat only selected objects of the case and thus has a scope describing the kinds of objects it may treat. A complex policy can thus be represented by a set of business rules in a simple way.
As there are numerous ways to represent a policy in terms of rules, additional criteria are necessary to determine good representations for decision automation. Firstly, it is important to keep the representation manageable and as small as possible. The number of rules can be reduced by making the rules as general as possible and by avoiding redundant rules. Secondly, different rules should be independent of each other in order to facilitate modification of rules due to a change of a business policy. If the business policy is changing for some cases, then the business user needs to adapt all rules treating this case to the new policy. If the rules are overlapping, then a policy change may require a modification of several rules. This overhead in rule editing is acceptable if the overlaps are due to the fact that the rules are as general as possible. However, it is not acceptable if there are redundant rules, which can be removed without changing the decision-making behavior of a rule set.
A manageable and agile representation of a business policy attempts to prohibit redundant rules. However, redundant rules are difficult to avoid if rules are automatically generated by rule learning and data mining tools or assembled from different sources, such as multiple rule authors. Due to the combinatorial nature of the rule conditions, there may be unforeseen interactions between rules, which lead to redundant rules even if the rules are written by a single author. For these reasons, existing business rule management and rule learning systems seek to eliminate redundancy by a dedicated rule analysis module.
Existing approaches for redundancy elimination differ in the form of redundancy that they are able to detect and in the form of rules that they are able to process. Most of these approaches consider simple forms of rules that make decisions for business problems involving a finite number of cases only. Those cases are characterized by a finite number of attributes over finite domains. As the number of those cases is finite, a redundancy analyzer can explore the set of treated cases of each rule. It can then compare these sets of treated cases for those rules that are making the same decision. Some redundancy analyzers limit this comparison to pairs of rules and determine whether a rule is made redundant by some other rule. For this purpose, such an analyzer checks whether all the treated cases of the examined rule are also treated by some other rule that makes the same decision. If yes, the analyzer notifies a local redundancy by stating that the first rule is made redundant by the other rule. Usually, such a local redundancy analyzer distinguishes between strict and simple redundancies. There is a simple redundancy between two rules if the two rules are equivalent, that is, make the same decision and treat exactly the same set of cases. A local analyzer may remove any of two equivalent rules to eliminate a simple redundancy. There is a strict redundancy between two rules if the second rule makes the first rule redundant, but the first rule does not make the second rule redundant. In order to eliminate a strict redundancy, the local redundancy analyzer will eliminate the redundant rule and not the other rule. This behavior is justified by the fact that the local redundancy analyzer has no knowledge of global redundancies.
A global redundancy analyzer seeks rules that are globally redundant, that is that can be removed from a rule set without changing the decision-making behavior of this rule set. A global redundancy analyzer detects a redundant rule if each of the treated cases of this rule is treated by some other rule in the rule set that makes the same decision as the examined rule. Locally redundant rules are also globally redundant, but the converse does not necessarily hold. For example, if the rules are mostly general conditions, then there are no locally redundant rules, but it may still be possible to remove some rules without changing the behavior of the rule set. It may even happen that all rules in a rule set are globally redundant and that removing some of these rules fixes all redundancies. Existing approaches to redundancy elimination focus on the problem of finding redundant rules, but do not address the full problem. The full redundancy elimination problem consists in finding a redundancy-free subset of the business rules that represents the same decision policy as the original rule project. The problem may take into account preferences between rules specifying which rules should be preserved and which rules should be eliminated if there are different ways for eliminating redundancies. Moreover the existing approaches for global redundancy elimination are limited to attributes over finite domains. For example, one approach checks whether a rule set makes a rule redundant by computing the number of cases that are treated by both the rule set and this rule. If this number is equal to the number of cases treated by the rule, then the rule is redundant. If it is strictly smaller than the number of cases treated by the rule, then the rule is not redundant. However, this reasoning is no longer valid if the rules are treating an infinite number of cases due to attributes with infinite domains (such as integer domains) such as:                r1: if the value of the customer is at least 1000 then set the category of the customer to “Gold”;        r2: if the age of the customer is at least 40 then set the category of the customer to “Gold”;        
Rule r1 is not made redundant by rule r2. Rule r1 treats all cases of customers having a value of at least 1000 and an arbitrary age. If no artificial bound is imposed on the value attribute, then there are an infinite number of such cases. Now rules r1 and r2 treat both all cases of customers having a value of at least 1000 and an age of at least 40. Again there are an infinite number of such cases. According to one approach, rule r2 thus makes rule r1 redundant, which is wrong.
Other approaches extend local redundancy analysis to business rules of arbitrary form, such as the redundancy analyzer of IBM WebSphere Ilog JRules BRMS 7.0 and 7.1. These approaches find redundancies among rules that make decisions for cases that are characterized by an unbounded number of objects and thus an unbounded number of attributes. Moreover, the attributes may have infinite domains. Those approaches use an implicit representation of the treated cases of the rules in form of constraint models and use logical problem solving methods to do a pairwise comparison of the treated cases of two rules. Although those approaches handle arbitrary rules, they only detect locally redundant rules and are insufficient to determine a redundancy-free policy-preserving subset of a rule set. IBM and WebSphere are trademarks in the US and/or other countries of International Business Machines Corporation.
Still other approaches use a different notion of redundancy. For example, one approach determines overlaps among the sets of treated cases of two rules and eliminates those overlaps by making one rule more specific, thus favoring overlap-freeness over generality.
Another approach detects and repairs conflicts between rules for network flow management enforcement. These rules are applied to given data packets and perform several actions on those packets, such as packet filtering by a firewall or load-balancing. These rules check whether given attributes of the data packets (‘fields’) match given bit strings. The bit string may consist of set bits, clear bits, and don't care bits. The rules are thus able to test whether a string of fixed length, such as an IP address, matches a given pattern, but are not able to test attributes with infinite domains. The approach compares each pair of individual rules and determines whether they treat disjoint, overlapping, or equal sets of data packets or whether one of these set is a subset of the other set. If the sets are overlapping, the approach repairs conflicts according to a priority policy. The approach can merge the two rules, modify the condition of one of the rules or include the actions of the higher priority rule into the action list of the lower priority rule. If the lower priority rule becomes redundant in this process, the approach deletes it.
The approach is thus able to eliminate a rule that is made redundant by a single other rule supposing that the condition of the rules are restricted to match operations on strings of fixed length. The approach cannot find redundancies between rules that involve attributes with infinite domains. For example, the approach is unable to treat rules of the following kind and to detect that rule r1 makes rule r2 redundant:                r1: if the value of the customer is at least 1000 then set the category of the customer to “Gold”;        r2: if the value of the customer is at least 2000 then set the category of the customer to “Gold”;        
More general rules may also differ in their scope, that is, match objects of different type, which poses particular difficulties for redundancy analysis. Those difficulties are not addressed by the patent application. Finally, another approach is unable to detect rules that are made redundant by a whole set of rules.
This approach facilitates the understanding of the filtering rules, optimizes the rule set, increases execution speed, and detects whether two filtering processes are equivalent. As each packet has a finite number of numeric attributes, the whole set of packets can be characterized in terms of a Cartesian space. Each filtering rule treats the packets within a rectangular region in this space. This supposes that the rule condition consists of interval membership tests and this is the same restriction that other approaches impose on the rules.
The approach splits Cartesian space into a set of minimum regions and characterizes each minimum region by a start and end point. This approach computes the relationship between the rules and the minimum regions treated by the rules. For this purpose, it processes the rules in the given preference order and labels the regions with the rules that cover them. If a rule covers only regions that are already covered by higher priority rules, then the approach says that the rule is concealed and eliminates it. Whereas the approach is thus able to compute a redundancy-free subset of the rules while preserving the decision-making behavior of the rule set, it has draw-backs. Firstly, it supposes that all rule conditions are interval membership tests. More complex tests involving arithmetic expressions and arbitrary comparison involving attributes with infinite domains are not handled by this. Secondly, the approach supposes that all rules match the same kind of object, namely a data packet, and cannot detect the relationship between rules that match different objects. For example, a rule that matches a customer object may make a rule matching a customer object and a shopping cart redundant. The approach does not provide any mechanism for handling rules matching different objects. Finally, the approach is prohibitive even for filtering rules as soon as these rules involve hundreds or thousands of attributes. For example, if there are already forty attributes and each attribute occurs in a test of some rule, then this will already generate a trillion of minimum regions. This explosion in space is the price of expanding the whole space that is covered by the rules.
The above examples show that existing approaches for redundancy analysis either impose limitations on the form of redundancies that they are capable to find or on the form of rules that they are capable to analyze. Moreover, there is no approach that treats the redundancy elimination problem as a whole and that is capable of computing a preferred redundancy-free and policy-preserving subset of business rules of arbitrary form.